How to be Early

When you should bet on technology#

As a technologist, you will frequently find yourself on either side of Geoffrey Moore’s “chasm,” either as an early adopter or as part of the early or late majority (see Strategic Awareness chapter for an in-depth explanation). The career upside, and risk, of betting on tech early is well understood, but it is worth discussing how early to be and where to take risks in the stack .

Managing risk#

Your primary job in betting on technology is to manage your overall technology risk while picking up new tech that helps you write better software. Technology is a means to an end. You should try to avoid making bets that could jeopardize your ultimate end goal.

If your goal is getting a job, your risk appetite is fairly low. Just aim to gain expertise in what your target companies already use. If you have job security or already have a stack that you are comfortable with, you have a higher risk appetite for expanding your toolkit. If you’re trying to do something truly cutting edge, you should be trying out all sorts of new and unproven approaches.

Innovation credits#

Thoughtbot and Echobind have a good approach that I liken to “Innovation Credit.” The rule is basically that when picking a stack for a client project, you’re only allowed to pick one or two new technologies to use, and everything else should be a familiar tech. They go so far as to allocate one day a week as “investment time” and budget in delays to their estimates for things to go wrong. You don’t have to go to the same extent, but allocating some exploration time is a great idea.

Know what’s missing#

As you build things and grow comfortable with your stack, you should be mindful of where your productivity isn’t as great as it could be. Some of the best developers you’ve heard of made their names because they have a “low bullshit tolerance,” leading them to create the tools, libraries, and languages that they then become famous for.

It turns out that a lot of developers share the same frustrations as you do, but they don’t do anything about it because they can’t imagine a better way or don’t mind working around the technology’s limitations.

Exposure therapy#

One way to inoculate yourself against acquiring “bullshit tolerance” is to occasionally look across the bow to other developer ecosystems. If you’re in full-stack JavaScript, check out Rails. If you’re in Rails, check out Laravel. If you’re in React Native, check out Flutter, and so on. You’ll see a lot of things that are the same or worse, but every now and then, you’ll find something that the community takes for granted, but you find mind-blowing. That’s an idea you should steal or a standard you should start demanding of your own stack.

I call this “exposure therapy”. It’s like a neat inverse to second system syndrome. You’re not evaluating things to switch; you’re opening your mind to what’s possible out there so that you don’t get too comfortable with the status quo. Conferences and YouTube channels are very good ways of exposing yourself to alternative ecosystems because you can try to understand ideas and observe effectiveness at a high level without getting lost in the details.

Keep a list of the problems#

Keep a list of the problems you constantly run into again and again. Here’s a list for UI Engineering. Solutions come and go; problems always remain.

When you know what you’re looking for, it’s easier to sift through the noise and evaluate new solutions. Having built a sense of what’s missing in your world, it’s much easier to go through the constant stream of new projects and launches to pattern match against how the new technology could fit in your workflow.

Evaluation#

Be careful to not only judge the project based on how it is today. If you’re early, there will almost always be problems with it. It may have lousy docs, be full of bugs, or have missing functionalities. This will make it look inferior to alternatives that exist today. This is not what you’re looking for. You’re looking for the core idea, the thing it does differently, and (assuming everything else is fixable…it is), how game-changing that would be to your world.

Paradigm shifts#

Ben Horowitz, of Andreesen Horowitz, is fond of explaining it this way: “New technology is usually inferior to existing alternatives in every way but one.” He applies it most to crypto, but we could easily argue this for NoSQL, React, or any other major new wave in tech. In Thomas Kuhn’s The Structure of Scientific Revolutions, he shows how almost every significant scientific breakthrough is first a break with tradition, old ways of thinking, and old paradigms. This is why we sometimes call them paradigm shifts.

Economics rewards evolution over revolution#

You should also be aware that the technically superior project often does not “win”. Sometimes this is because the superior qualities require too much change, whereas the “less superior” project compromises technical merit for compatibility. Economics rewards evolution over revolution. This happens again and again in tech history, from VHS vs. Betamax to React + Redux + TypeScript vs. Elm. Of course, in personal projects, you shouldn’t need to care who “wins”, but this changes when you are trying to bet on a winner for career or investment purposes.

Don’t surf every wave#

Even after careful risk management, selection, and evaluation, there are still many people who try to keep up with every new thing. Unless this is your sole job, don’t do this. It is a fast track to burnout. Try to have an investment thesis for how the technology fits into a longer-lasting megatrend that makes your investment worth it.

Dave Rupert of the “Shop Talk Show” has a great analogy for this:

“When you surf, if you paddle for every wave, you just get destroyed… You’re hurt and out of breath, and it’s dangerous, to be honest because you could literally drown. You see the good surfers. They just effortlessly paddle out. They figured out how to do that. They sit out there until a big wave comes. They know how to find a big wave. Then they say, ‘Yeah, I’ll ride that big wave because that big wave is worth my time.’ They don’t waste energy. All energy is put towards good surfing.”

People#

The other factor to weigh heavily is the people behind the project. If the project maintainers have a track record of running high-quality projects, you should upgrade your interest level immediately. Of course, famous maintainers will already have this halo effect surrounding all their work. You should also be paying attention to the lesser-known ones, who aren’t as much in the limelight but who steadfastly put out quality open source and tooling that you rely on.

Involve yourself as a maintainer#

When it comes to people involved early in a new project, you have an ace in your hand. You. When you choose to become actively involved as a maintainer/contributor, instead of just as a passive user, you gain the power to affect the direction and potential upside of the technology.

Being early is the best time you can tie your career to technology and grow as it grows. You basically buy a career call option on the tech, which is even better than owning equity. If it works out, your career benefits from your involvement and contributions. Jessie Frazelle’s career rose with Docker, Charity Majors’s with MongoDB, Ryan Florence’s with React, Kelsey Hightower’s with Kubernetes. None were project originators; all just decided to join while still early and reaped the rewards of the contributions.

“The best way to predict the future is to create it.”

- Dennis Gabor

It shouldn’t come as a surprise that when betting on technology, it isn’t just about the technology itself. Technology happens as the result of superhuman efforts by very human people, and betting on tech is almost the same as betting on the people.

It is with this framing that we come to the topic of project values.